Networked computing has increased the functionality of computers by enabling computers that are physically located at different places to share information as well as applications. A networked computer can access applications and data stored on computers that are located far away, just as if the applications and the data are stored locally. This can increase efficiency since the applications and the data do not need to be installed at each computer, which could mandate a significant increase in computer management resources to provide necessary support. Furthermore, expenses can be reduced since application licenses do not need to be purchased for every computer that can potentially make use of the applications. Rather, a license that specifies a number of concurrently running copies of the application can be purchased and any number of computers can then execute the application, as long as the number is less than or equal to the licensed number.
With reference to FIG. 1, there is shown a diagram illustrating an exemplary networked computing environment 100. The exemplary networked computing environment 100 includes a first workstation 105 that is operated by a first user “user 1” and a second workstation 106 that is operated by a second user “user 2.” The first workstation 105 and the second workstation 106 can be connected to a network 110 that permits the workstations 105 and 106 to access applications and data stored on a database server 115, a first server 120, a second server 125, another workstation 130, and so forth. The workstations 105 and 106 may be in close proximity to these other computers (located in the same room, building, or campus, for example) or the computers of the networked computing environment 100 may be located in different cities, states, countries, continents, and so forth. While the first workstation 105 is accessing applications and data stored on one or more of the other computers, the second workstation 106 can also be accessing applications and data stored on one or more of the same computers. For example, the first user on the first workstation 105 can be accessing data via the data-base 115 while the second user on the second workstation 106 may be authoring a data-base queries on the data-base 115.
Access to the applications and the data can be controlled by authenticating users. For example, before a user can launch an application, the user's identity may need to be authenticated. This can be achieved by interrogating the user to provide the requisite access requirements, such as account name and password. If the account name and password can be verified and the user is on an allowed list of users, then the application can be executed. Unfortunately, the need to enter repeatedly the access requirements to different applications and/or computers can become tedious over the course of a day's work.
In order to simplify the sharing of applications and data in the networked computing environment, a technique referred to as single sign-on (SSO) that requires a user to authenticate only one time per session within a given period of time can be used. As long as the user continues to access shared applications and data within a given time period, the user will not be required to authenticate each time new applications or data are accessed. SSO does not eliminate the need to authenticate the user, rather, the authentication occurs in the background, without requiring user input or intervention.
With reference now to FIG. 2, there is shown a diagram illustrating a prior art technique for implementing SSO in a networked computer environment. The diagram shown in FIG. 2 illustrates high-level views of software present in exemplary computers in the networked computer environment. The networked computer environment, as shown in FIG. 2, includes two computers, a first computer 200 and a second computer 250. The two computers are coupled together via a network (not shown). The first computer 200 includes a plurality of applications, such as application “app—1” 205 and application “app_N” 206.
The application “app—1” 205 has been modified to support SSO and in conjunction with an SSO plugin 210, which can be a custom designed application that is specifically written for the application “app—1” 205 and an operating system 220 executing on the first computer 200, users of the application “app—1” 205 can make use of SSO. The SSO plugin 210 can serve as an interface between the application “app—1” 205 and an SSO provider 215, operating as a bridge between the application “app—1” 205 and the SSO provider 215. The SSO provider 215 can provide the necessary support for single sign-on on the first computer 200, such as storage of authentication information, authorizing users, interfacing multiple applications, and so forth. The application “app_N” 206 has not been modified to support single sign-on, so there is no attendant SSO plugin. Although shown in FIG. 2 as being located in the first computer 200, the SSO provider 215 may be located on a remotely located, centralized host, for example, an SSO host or even on the second computer 250. In general, there is a single logical SSO provider 215 executing within a single networked computing environment.
When a user requests access to an application, such as the first application 205, the SSO plugin 210 can access the SSO provider 215 to authenticate the user. If the user is already authenticated, then the user can be permitted to access the application (if the user has adequate permission to do so). If the user has not been authenticated, then the user will need to authenticate and then access to the application can be granted. Although not shown, an SSO token (authentication information) can be passed between applications upon an attempt by a user to launch an application. For example, the SSO provider 215 can provide the SSO token to the first application 205, permitting the user to launch a second application “APP—2” 207. The SSO token may contain important information pertaining to the user as well as permission level, and so forth, and should therefore be protected to an adequate degree.
An operating system (OS) 220 provides functional control of the operations of the first computer 200, while a communications (COMM) stack 225 permits the first computer 200 to communicate with other computers in the networked computing environment. Different computers can utilize different operating systems, with examples of operating systems being Windows®, Unix, Linux, MacOS®, JAVA®, and so forth. The second computer 250 can contain a set of software applications, operating systems, SSO plugins, and communications stack that may be similar to or different from the first computer 200.
One disadvantage of the prior art is that an SSO plugin is required for every combination of application, application to be launched, SSO provider, and operating system used in the network computing environment. This can lead to a large number of different SSO plugins that will make support of the network computing environment expensive and potentially error prone.
Another disadvantage of the prior art is that if an SSO plugin is not available for a particular application, SSO provider, and operating system being used, then a different SSO application may be needed, with interoperability between different SSO applications not ensured.
A primary disadvantage of the prior art is that SSO tokens are transferred between the various applications, such as the requesting application, the application being requested, the SSO provider, the SSO plugin, and so forth. Extensions must be added to each SSO enabled application to ensure that the SSO tokens are transferred in a secure manner, particularly between applications on different computers in the networked environment.